Video camera with live streaming capability

ABSTRACT

Systems and methods for streaming video and/or audio from wireless cameras are provided. A camera may include an optical sensor, a wireless communication device, and a processor configured to establish a connection with a remote web site, and stream a first video stream to the remote website. The camera may be further configured to establish a connection with a local device, and stream a second video stream to the local device. The first and second video streams may include different resolutions and/or different formats. The camera may be configured to establish a control channel with the local device.

RELATED APPLICATIONS

The present application claims the benefit of U.S. ProvisionalApplication No. 61/681,981, entitled WIRELESS VIDEO CAMERA ANDCONNECTION METHODS, filed Aug. 10, 2012; U.S. Provisional ApplicationNo. 61/713,429, entitled WIRELESS VIDEO CAMERA AND CONNECTION METHODSINCLUDING A USB EMULATION, filed Oct. 12, 2012; and U.S. ProvisionalApplication No. 61/713,440, entitled WIRELESS VIDEO CAMERA ANDCONNECTION METHODS INCLUDING MULTIPLE VIDEO STREAMS, filed Oct. 12,2012, the contents of which are hereby incorporated by reference intheir entireties.

BACKGROUND OF THE INVENTION

Embodiments of the present invention generally relate to the managementand operation of network cameras and the provision of multiple videostreams from a single camera. More particularly, embodiments of thepresent invention relate to simultaneous sending of multiple videostreams to different nodes based on common video capture data, and maybe sent at, for example, different bitrates, different resolutionsand/or different frame-rates.

Many cameras today provide an interface to produce specific videostreams over a network interface, such as over real-time streamingprotocol (RTSP) or over HTTP streaming, such as Apple's HTTP LiveStreaming, Adobe's HTTP Dynamic Streaming, or Microsoft's HTTP SmoothStreaming. Similarly many of these cameras allow the simultaneousstreaming of different versions of a stream. These cameras lack theability to intelligently interact with online video services and localcomputers and to optimally use multiple video streams sent to differentnetwork destinations for different network purposes.

SUMMARY OF THE INVENTION

According to first aspects of the invention, a method of establishing astreaming video session may include, at a network camera, receiving aninstruction to begin video capture from a first network node, includinginformation identifying a second network node; sending a first videostream to the first network node; and simultaneously sending a secondvideo stream to the second network node. In embodiments, the first andsecond video streams may be based on the same common video capture data,and the first and second video streams may be sent at, at least one of:different bitrates, different resolutions or different frame-rates.

Embodiments may include adjusting a parameter of the second video streamin response to performance data received from at least one of the secondnetwork node or another network node.

In some embodiments, the performance data may include at least one oflatency, audio quality, video quality, and processor workload.

In some embodiments, adjusting the parameter of the second video streammay include changing at least one of a video resolution, a compressionratio, a compression rate, a frame-rate, and a key-frame interval.

In some embodiments, adjusting the parameter of the second video streammay include selecting the parameter to be adjusted from a plurality ofparameters based on at least one of the performance data, an analysis ofthe first video stream, an analysis of the second video stream.

Embodiments may include adjusting parameters of multiple network camerassharing a common Internet connection to one or more second networknodes.

Embodiments may include adjusting compression ratios between the firstand second video streams based on the performance data.

Embodiments may include receiving information indicating that thequality of an audio stream is below a predetermined threshold, andreducing the bitrate of the second video stream.

In some embodiments, the network camera may be connected to a wirelessnetwork, the first network node is a computing device locally connectedto the wireless network, and/or the second network node is one of aremote device or service that is in communication with the networkcamera or the computing device via the Internet.

According to further aspects of the invention, a camera may be providedincluding an optical sensor; and a processor configured to send a firstvideo stream of a first resolution to a local device; and send a secondvideo stream of a second resolution to a remote device.

In some embodiments, the first stream may be sent wirelessly.

In some embodiments, the second stream may be sent wirelessly.

In some embodiments, the camera may be further configured to wirelesslyobtain performance data related to the first or second video streams,and to adjust a parameter of the second video stream in response to theperformance data.

In some embodiments, the processor may be configured to send the firstand second video streams over a common local area network.

In some embodiments, the first stream may be sent over a wiredconnection to the local device.

In some embodiments, the processor may be further configured toestablish a control channel between the local device and the camera.

In some embodiments, the processor may be further configured toestablish a link with a remote website associated with the remotedevice, and to control video streaming to the remote site via anapplication running on the camera.

In some embodiments, the processor may be further configured to respondto control signals sent from the local device, and to control theapplication running on the camera based on the control signals.

In some embodiments, the processor may be further configured toestablish a wireless connection between the local device and the camera.

In some embodiments, the first and second resolutions may be different.

According to further aspects of the invention, a method of sharing videodata between a camera, a host device and a remote service, may beprovided including on or more steps of establishing a first wirelessconnection between the camera and the host device; establishing a secondconnection between the host device and the remote service; sendingidentification information related to the camera from the host device tothe remote service; and/or receiving a video stream at the host devicefrom the remote service based on the identification information. Inembodiments, the video stream may be communicated from the camera to theremote service without being processed by the host device, and the videostream is communicated from the remote service to the host devicewithout further processing by the camera.

In some embodiments, the first wireless connection may include a controlchannel for allowing the host device to control the camera.

In some embodiments, the first wireless connection may include a videochannel for allowing the host device to receive another video streamfrom the camera.

In some embodiments, the host device may be at least one of a personalcomputer, a smart phone or a remote control.

Embodiments may include establishing a plurality of wireless connectionsbetween the host device and a plurality of devices including the camera,wherein establishing the plurality of wireless connections includes aprotocol negotiation based on one or more of an anticipated powerrequirements analysis for the plurality of devices, an anticipated usagerequirements analysis for the plurality of devices, and anticipated ormandated security requirements associated with the plurality of devices.

In some embodiments, a camera may include an optical sensor; a wirelesscommunication device; and a processor configured to establish aconnection with a remote web site, and stream a first video stream tothe remote website. The first stream may be sent wirelessly. Theprocessor may be further configured to: establish a connection with alocal device, and stream a second video stream to the local device. Insome embodiments, the first and second video streams include differentresolutions, may be sent using different formats, and/or may includedifferent audio formats. In some embodiments, the second stream may besent wirelessly.

In some embodiments, the processor may be further configured toestablish a control channel between the local device and the camera.

In some embodiments, the camera may be further configured to wirelesslyobtain performance data related to the first or second video streams,and to adjust a parameter of the second video stream in response to theperformance data.

In some embodiments, the processor may be configured to send the firstand second video streams over a common local area network.

In some embodiments, the camera may be further configured to wirelesslyobtain performance data related to the first video stream, and to adjusta parameter of the first video stream in response to the performancedata.

In some embodiments, the processor may be further configured to controlthe first video stream via an application running on the camera.

In some embodiments, the processor may be further configured to:establish a connection with a local device, respond to control signalssent from the local device, and control the application running on thecamera based on the control signals.

In some embodiments, the processor may be further configured toestablish a wireless connection between the local device and the camera.

In some embodiments, the processor may be further configured to:establish a connection with at least one other camera, and stream videofrom the at least one other camera to the remote website. In someembodiments, the processor may be further configured to: provide controlsignals to the at least one other camera, and control an applicationrunning on the at least one other camera based on the control signals.In some embodiments, the at least one other camera may include aplurality of cameras.

In some embodiments, the processor may be further configured to streamthe video from the at least one other camera to the remote website withthe first video stream. In some embodiments, the processor may befurther configured to stream the video from the at least one othercamera to the remote website as a second video stream.

In some embodiments, a camera may include an optical sensor; a wirelesscommunication device; and a processor configured to establish a firstconnection with a remote location, establish a second connection with atleast one other camera, and stream video from the camera and video fromthe at least one other camera to the remote location. In someembodiments, the remote location is at least one of a remote website, aremote server, and a remote client device.

In some embodiments, the processor may be configured to stream the videofrom the camera with the video from the at least one other camera to theremote location. In some embodiments, the processor may be configured tocombine the video from the camera with the video from the at least oneother camera. In some embodiments, the processor may be configured tostream the video from the camera to the remote location as a first videostream and the video from the at least one other camera to the remotelocation as a second video stream. In some embodiments, the processormay be configured to switch an outgoing video stream between the firstvideo stream and the second video stream.

In some embodiments, the remote location may be a remote website, andthe processor may be configured to stream the video from the camera andthe video from the at least one other camera to the remote website via alocal wireless network connected to the internet.

In some embodiments, the camera connects with the at least one othercamera via at least one of, for example, wifi, Bluetooth, and aninternet router.

Additional features, advantages, and embodiments of the invention may beset forth or apparent from consideration of the following detaileddescription, drawings, and claims. Moreover, it is to be understood thatboth the foregoing summary of the invention and the following detaileddescription are exemplary and intended to provide further explanationwithout limiting the scope of the invention claimed. The detaileddescription and the specific examples, however, indicate only preferredembodiments of the invention. Various changes and modifications withinthe spirit and scope of the invention will become apparent to thoseskilled in the art from this detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention, are incorporated in and constitute apart of this specification, illustrate embodiments of the invention andtogether with the detailed description serve to explain the principlesof the related technology. No attempt is made to show structural detailsof technology in more detail than may be necessary for a fundamentalunderstanding of the invention and various ways in which it may bepracticed. In the drawings:

FIG. 1 is an illustrative network topology according to one embodimentof the present invention;

FIG. 2 is an illustrative connection sequence according to oneembodiment of the present invention;

FIG. 3 is a illustrative block diagram of a user device according to oneembodiment of the present invention;

FIGS. 4A and 4B are illustrative machine-readable features according tovarious embodiments of the present invention;

FIG. 5 is an illustrative connection parameter format according to oneembodiment of the present invention; and

FIGS. 6, 7, and 8 are illustrative processes for supporting automaticdevice connection or device pairing according to various embodiments ofthe present invention.

FIG. 9 shows an embodiment of the invention where the virtual USB camerais implemented as a component running in user space sending USB commandsto a virtual USB bus running in kernel space.

FIG. 10 shows an embodiment of the invention where a single componentrunning in kernel space implements a virtual USB camera and a virtualUSB bus to which the camera is connected.

FIG. 11 shows an embodiment of the invention including a bus enumerator.

FIG. 12 shows details related to an IP component supporting multiplecameras according to aspects of the invention.

FIG. 13 schematically illustrates details related to a “broadcaster”camera with virtual audio and video features according to aspects of theinvention.

FIG. 14 schematically illustrates further details related to virtualaudio features according to aspects of the invention.

FIG. 15 schematically illustrates details related to an alternativecontrol interface according to further aspects of the invention.

DETAILED DESCRIPTION OF THE INVENTION

It is understood that the invention is not limited to the particularmethodology, protocols, etc., described herein, as these may vary as theskilled artisan will recognize It is also to be understood that theterminology used herein is used for the purpose of describing particularembodiments only, and is not intended to limit the scope of theinvention. It also is to be noted that as used herein and in theappended claims, the singular forms “a,” “an,” and “the” include theplural reference unless the context clearly dictates otherwise. Thus,for example, a reference to “a camera” is a reference to one or morecameras and equivalents thereof known to those skilled in the art.

Unless defined otherwise, all technical terms used herein have the samemeanings as commonly understood by one of ordinary skill in the art towhich the invention pertains. The embodiments of the invention and thevarious features and advantageous details thereof are explained morefully with reference to the non-limiting embodiments and examples thatare described and/or illustrated in the accompanying drawings anddetailed in the following description. It should be noted that thefeatures illustrated in the drawings are not necessarily drawn to scale,and features of one embodiment may be employed with other embodiments asthe skilled artisan would recognize, even if not explicitly statedherein. Descriptions of well-known components and processing techniquesmay be omitted so as to not unnecessarily obscure the embodiments of theinvention. The examples used herein are intended merely to facilitate anunderstanding of ways in which the invention may be practiced and tofurther enable those of skill in the art to practice the embodiments ofthe invention. Accordingly, the examples and embodiments herein shouldnot be construed as limiting the scope of the invention, which isdefined solely by the appended claims and applicable law.

Embodiments of the present invention generally relate to the managementand operation of network cameras and the provision of multiple videostreams from a single camera. More particularly, embodiments of thepresent invention relate to simultaneous sending of multiple videostreams to different nodes based on common video capture data, and maybe sent at, for example, different bitrates, different resolutionsand/or different frame-rates.

Embodiments of the present invention may provide systems and methods forfacilitated or automatic connection or pairing of network cameras usingmachine-readable features, such as machine-readable indicia and audiosignals. A first device may acquire a machine-readable feature in orderto initiate an automatic device connection or pairing process with asecond device (or with a plurality of devices). The device connection orpairing process may be “automatic” in that no additional userintervention or user input may be required to complete the deviceconnection or pairing process. For example, a scanner or cameracomponent associated with a network camera may optically acquire abarcode in order to initiate automatic Bluetooth pairing between thenetwork camera and any number of other Bluetooth devices, such asperipherals. Similarly the network camera can scan a barcode to access aWiFi network and or one or more online services. If more than onenetwork protocol is supported between the first device and the seconddevice, one or more of a power requirements analysis and a usagerequirements analysis may be performed. One network protocol of the morethan one supported network protocols may be selected for use inestablishing a connection between the first device and the second devicebased, at least in part, on the power requirements analysis, the usagerequirements analysis, or both the power requirements analysis and theusage requirements analysis. After the first device and the seconddevice have connected or paired a first time, connection parameters maybe stored to one or both devices.

Embodiments of the present invention further provide systems and methodsfor establishing video streams from a network camera. A network cameramay be used for a video call and the camera may receive an indicationfrom a device used to set up the call to send one video stream directlyfrom the camera to a remote computer, and a different video stream backto the computer initiating the call. These streams may be of differentquality and formats depending on a number of properties of each terminalof the video call. In an embodiment of the invention, the camera isauthenticated with an online video-call service wherein the servicedirectly instructs the camera where to send video data. Embodiments ofthe present invention further provide systems and methods for optimizingquality and performance of video, audio and other data streams relatedto network cameras, and means for synchronizing audio and video datareceived from multiple sources, including multiple network cameras.

An embodiment of the invention includes a network camera that can beused in conjunction with online video services including videoconferencing services. The camera may have the ability to capture videousing an imaging sensor and encode the video in a number of resolutionsand formats. The network camera may also include one or more microphonesto capture audio. For example, the camera may have an image sensor witha resolution of 4096 by 1714. In an embodiment of the invention, thecamera may stream video in resolutions under 1920 by 1080. The cameramay include the ability to encode video in a number of video formatsincluding H.264 (MPEG 4 Layer 10), Motion JPEG (MJPEG), Web M, H.263 andmore. The camera may be able to convert video captured using the imagesensor to a lower resolution and encode it using one of the supportedvideo formats. Similarly, the camera may be able to encode a section ofthe captured video as a lower resolution stream, for example the topleft corner of a VGA stream may be encoded as a QVGA stream. Forexample, the camera may encode an H.264 stream at 640 by 480 pixels at20 frames per second at 1 mbps.

In an embodiment of the invention the network camera sends a singlevideo stream to a single destination. That destination may be the remoteparty of a video call, a video repository or any other destination. Inanother embodiment of the invention, the network camera may transmitmultiple video streams to one or more destinations at generally the sametime. For example, if the network camera is used to facilitate a videocall, the camera may send one network stream to the remote party, andone network stream to the local party such that the local party cansupervise the outgoing video stream. The stream sent to the remote partymay be optimized based on the equipment at the remote party and thenetwork conditions between the network camera and the remote party. Forexample, only a limited amount of bandwidth may be available between thenetwork camera and the remote party. The camera may dynamically adaptthe stream to the remote party to compensate for these conditions, andin some embodiments send video data directly to the remote party,bypassing the local host computer.

In an embodiment of the invention, the camera received feedback from theremote destination regarding latency as well as audio and video quality,processor workload and other variables impacting quality. The networkcamera may then adjust the properties of the video stream to ensureoptimum quality. For example, after receiving notification from theremote party that audio quality is suffering, the network camera maymake adjustments to the video stream to reduce the amount of networkbandwidth consumed by the video stream to free up capacity for the audiostream. Similar adjustments may be made if the video quality of the callsuffers.

In an embodiment of the invention, where multiple network applicationsand or network cameras share an internet connection, they may coordinatebandwidth usage to optimize the quality of all applications. Forexample, two users in a household sharing an internet connection may beconducting two video calls using two separate network cameras. In anembodiment of the inventions, the two network cameras may coordinate thebandwidth used for audio and video in order to ensure that both calls donot suffer packet loss and stutter in video or audio.

Bandwidth restrictions may be caused by a number of factors. Whensending a video stream from one user to another, there may be abottleneck at the local network of the sending user, including thewireless network, at the internet connection of the sending user, at theinternet connection of the receiving user, or at the local network ofthe receiving user. Furthermore, network traffic between the two usersmay be impacted by network performance between the two users internetservice providers. When a network camera detects a reduction inperceived video quality, different mitigation measures may be employeddepending on what causes the network performance issues.

For example, if the network camera is sending multiple high-bandwidthstreams to local users as well as a bandwidth limited stream to a remoteuser, the capacity of the wireless connection of the camera or the localwireless network may be exhausted, while the capacity of the user'sinternet connection may still have spare capacity. Reducing the qualityof the remote stream may in such a case have little impact ontransmission issues perceived at the remote party, and the camera mayinstead improve transmission by reducing the quality of one or more ofthe much higher bandwidth local streams to free up capacity in the localwireless network and let the remote stream pass with less latency andpacket loss.

When adjusting a video stream to compensate for network performance, thevideo stream may be adjusted in a number of ways. For example, thenetwork camera may change the video resolution, the compression ratio,the frame-rate, the key-frame interval, the compression rate, thecompression quality or other parameters. In an embodiment of theinvention, the network camera may analyze the content of the videostream to select the best way to optimize the video. For example, ifthere is little movement in the video, the camera may reduce theframe-rate, whereas if there is a lot of movement in the video, thenetwork camera may reduce the video resolution.

The network camera may have video encoding capability built in hardwareand or video encoding capability implemented in software. In eithercase, encoding different types of video streams may require a higher orlower portion of the overall encoding capacity of the network camera.For example, encoding a high-resolution, high-bandwidth H.264 stream,requires significantly more processing power than encoding aVGA-resolution MJPEG stream.

In an embodiment of the invention, the camera may dynamically allocatevideo compression capacity between streams based on how the streams areperforming. For example if a remote video-stream is underperforming dueto low bandwidth at the remote network, the network camera may reducethe bandwidth required by increasing the compression ratio and thecompression quality of the stream by diverting more compressionresources to the stream, while diverting compression resources away froma local video stream. The quality of the local video-stream may becompensated by increasing the bandwidth while reducing the compressionratio.

The network camera may include the ability to perform image manipulationon a video stream. For example, when the network camera is sending avideo stream to a local party in a video call for them to monitor theirown image, the network camera may reflect the image in the stream tomake the video-feed resemble a mirror image. This may eliminate the needfor the local device to perform this transformation. Similarly, thecamera may include other video processing capabilities such as theability to adjust color levels, contrast and brightness or other videotransformations. In an embodiment of the invention, these can beadjusted individually per stream to adapt to the requirements of eachparty.

In an embodiment of the invention, multiple network cameras may be usedto provide different video data for the same target. For example, twowireless network cameras may be placed at different angles to capture anevent. In a meeting one camera may be used to capture a wide-angle imageof the entire room, while one camera may be used to capture a macro viewof the current speaker. More than two cameras are also possible. Forsuch a scenario, the two cameras may synchronize their streams in orderto ensure satisfactory performance of both video streams and anaccompanying audio stream. The two network cameras may first synchronizetheir clocks to ensure that they simultaneous frames match up with eachother and with the audio stream. Furthermore, the bandwidth of the twostreams may be coordinated to ensure smooth delivery of both. Forexample, a high frame-rate video stream may be selected for the streamcapturing the macro-view of the current speaker to ensure that lipmovement is represented clearly and in sync with the audio. The wideangle view of the entire room may be shown in a higher resolution to getmore detail, but at a lower frame-rate since there is less relativemovement in the picture.

In an embodiment of the invention, the video-stream quality is assessedprior to the encoding of every key-frame in the video stream as this isthe point in time when a change to the stream may be implemented withthe least delay. The assessment may be done at a lower frequency. In adifferent embodiment, the key-frame interval may be adjusted in responseto network events.

In an embodiment of the invention, a network camera may be used tosimulate a web-camera attached to a computer via a USB cable or otherinterface. In an embodiment of the invention a driver is installed onthe computer to enable the use of the network camera as a local camera.The implementation of the driver on the computer and the communicationsinterface on the camera may vary depending on the target platform on thecomputer.

In an embodiment of the invention a driver may simulate a USB deviceconnected to a computer and encapsulate USB commands into internetprotocol (IP) packets sent to the network camera. This implementationmay minimize the complexity of the computer driver and may permit thedriver to rely on existing operating-system support for USB cameras. Thenetwork camera may then process the received USB commands as if theywere transmitted over a conventional USB connection.

In another embodiment of the invention the driver may be more complexand implement a full interface to the operating system digital videoapplication programming interfaces (APIs). For example a windows drivermay interface with the Direct Show framework. This approach may be moreflexible in that the interface between the computer and the networkcamera may be optimized for IP transport and may therefore not bedependent on USB specifications and communications standards. Similarlyit may permit a more uniform implementation on the camera. This approachmay however require more complex drivers as they to a larger degree mustinterface with operating-system specific APIs for video.

In one embodiment of the invention a hybrid approach is taken, wherecustom drivers interfacing directly with the operating system video API,such as direct show is used for some operating systems, and a USBsimulation is used for less common ones.

In an embodiment of the invention, a USB simulator may run as a serviceon the camera that produced one video stream, while allowing the camerato serve other video streams, either as additional simulated directlyattached cameras or as network streams.

FIG. 1 is simplified schematic of a network 100 according to oneembodiment of the present invention. Network 100 may include anywireless network associated with a WLAN, PAN, or any other wirelessnetwork. For example, network 100 may be a Bluetooth wireless network. Auser terminal or device supporting the Bluetooth standard may establisha wireless connection with neighboring Bluetooth devices usingpoint-to-point connections. A master-slave arrangement may be used withone master device communicating with up to seven slave devices, forexample, in a network group called a piconet.

According to one embodiment, network 100 includes a device 102, whichmay be the master device, and devices 104, 106, 108, and 110, which maybe slave devices in the same piconet as device 102. Device 102 mayestablish a wireless connection with neighboring devices 104 through 110by executing an inquiry procedure and a paging procedure. After theinquiry procedure and paging procedure, a user of device 102 may selecteach of devices 104 through 110 from a menu or list of devices that arein range. Alternatively, an automatic procedure may be initiated byacquiring a machine-readable feature with device 102. In someembodiments, each of devices 102, 104, 106, 108, and 110 may beBluetooth devices or WiFi devices. The machine-readable feature acquiredby device 102 may be used to access connection parameters (e.g., networkaddress information) about one or more of devices 104 through 110. Theconnection parameters may include information required to establishconnections with devices 104 through 110. For example, depending on theprotocol used, a network address (e.g., Bluetooth address) for each ofdevices 104 through 110 may be used to establish connections to devices104 through 110. Other connection parameters, such as authentication andother security information, may also be included in the connectionparameters that are accessed via the machine-readable feature.

For example, Bluetooth includes several security features. Bluetoothimplements confidentiality, authentication, and key derivation usingcustom algorithms based on the SAFER+block cipher. Bluetooth keygeneration is generally based on a Bluetooth PIN, which must be inputinto both devices. This procedure might be modified if one of thedevices has a fixed PIN (e.g., for headsets or similar devices with arestricted user interfaces). During device connection, an initializationkey or a master key is generated, using the E22 key generationalgorithm. The E0 stream cipher is used for encrypting packets and isbased on a shared cryptographic secret, namely a previously generatedlink key or master key. Those keys, used for subsequent encryption ofdata sent via the wireless interface, rely on the Bluetooth PIN, whichhas been input into one or both devices. The connection parametersaccessed via the machine-readable feature acquired by device 102 mayinclude any such PIN values, link keys, and/or master keys.

In some embodiments, device 102 may be, for example, a wireless camera,or smartphone. The device 102 may be configured to establish a firstconnection with a remote location, such as a remote website, a remoteserver, and/or a remote client. The first connection may include, forexample, a wifi connection to a router, and an internet connection tothe remote device. Device 102 may further be configured to establish asecond connection with at least one other device 104, 106, 108, and 110,such as a camera, smartphone or other client device, and to stream videofrom the device 102 and video from the at least one other device to theremote location.

The device 102 may be configured to stream the video from the device 102with the video from the at least one other device to the remotelocation. In some embodiments, the device 102 may be configured tocombine the video from the device 102 with the video from the at leastone other device. In some embodiments, the processor may be configuredto stream the video from the device 102 to the remote location as afirst video stream and the video from the at least one other device tothe remote location as a second video stream. In some embodiments, thedevice 102 may be configured to switch an outgoing video stream betweenthe first video stream and the second video stream.

In some embodiments, the remote location may be a remote website, andthe device 102 may be configured to stream the video from the device 102and the video from the at least one other device to the remote websitevia a local wireless network connected to the internet.

By way of further example, the above embodiments may provide, amongother objects, multi-camera broadcasting with one camera as a master,that pumps data to, for example, wifi connection over router to upstreamservers and/or websites. The master camera connect to other videosources that are slaves. The master camera can also decide to switch andpump the separate or combined video in the same session, as mixedstreams, etc., to a server or website. It should be understood that theprotocols described above may also be performed by other mobile devices,and may be used to, for example, send video to video hosting or otherwebsites, to remote storage and access sites, to other people vianetwork addresses, phones, local hotspots etc.

Each wireless connection between device 102 and devices 104 through 110may include a point-to-point bi-directional or uni-directional link. Thewireless connections may be connection-oriented or connectionless.Various error-detection, error-correction, and wireless medium accesscontrol (MAC) schemes (e.g., CSMA/CD) may be used. Although device 102is wirelessly connecting to only four devices 104 through 110 in theexample of FIG. 1, device 102 may wirelessly connect to more or fewerdevices in network 100 in other embodiments. In addition, the protocolsused by device 102 to wirelessly connect to devices 104 through 110 maybe the same or different protocols. For example, the 802.11 protocol maybe used by device 102 to wirelessly connect to devices 104 and 110whereas the Bluetooth protocol may be used to wirelessly connect todevices 106 and 108. Some devices in network 100 may support more thanone protocol (e.g., 802.11 and Bluetooth).

In some embodiments, device 102 automatically connects to one or more ofdevices 106 through 110 using a negotiated protocol. As described inmore detail with regard to FIG. 7 below, the protocol negotiation may bebased on one or more of an anticipated power requirements analysis forthe devices, an anticipated usage requirements analysis for the devices,and anticipated or mandated security requirements. For example, somedevices may support more than one wireless protocol (e.g., 802.11 andBluetooth). Depending on the anticipated mobility of the devices, theanticipated applications to be used on the devices, and a powerrequirements analysis, the most appropriate protocol may be negotiatedautomatically. In some embodiments, the protocol with the lowesttransmit power or range is selected for use unless that protocol is notsuitable for the anticipated usage of the devices. In some embodiments,the protocol with the strongest security policy (e.g., encryption orauthentication) is selected for use unless that protocol is not suitablefor the anticipated usage of the devices. In some embodiments, theprotocol with the lowest transmit power or range and the strongestsecurity policy (e.g., encryption or authentication) is selected for useunless that protocol is not suitable for the anticipated usage of thedevices.

FIG. 2 shows an illustrative connection sequence 200 between a firstdevice and one or more other devices according to one embodiment of thepresent invention. Connection sequence 200 may be used to determinewhich devices are in range of a device initiating connection sequence200 and to connect to one or more of these other devices. Normally, awireless connection (e.g., a Bluetooth connection) between two devicesis initiated with an inquiry procedure 202. Inquiry procedure 202enables the first device to discover other devices that are in range.Inquiry procedure 202 may also determine the addresses and clocks forthe other devices that are in range of the first device. During inquiryprocedure 202, the first device may transmit inquiry packets and receiveinquiry replies. The other devices that receive the inquiry packets maybe in an inquiry scan state 204 to receive the inquiry packetstransmitted by the first device. The other devices may then enter aninquiry response state 206 and transmit an inquiry reply to the firstdevice. After the inquiry procedure is completed, a connection may beestablished using a paging procedure 208. Paging procedure 208 typicallyfollows inquiry procedure 202. Although the device address (e.g.,Bluetooth address) may be required to establish a connection, someknowledge about the master device's clock (e.g., a clock estimate) mayaccelerate the setup procedure.

Paging procedure 208 may begin with the first device paging one or moreother devices (e.g., slave devices) that are in a page scan state 210.The slave device may transmit a reply to the page to the first deviceduring a slave response state 212. During a master response state 214,the first device may transmit a frequency hopping synchronization (FHS)packet to the other devices. The FHS packet may include the firstdevice's address and clock information. The other devices then send asecond reply to the first device in slave response state 212. The firstdevice and the other devices then switch to the first device's channelparameters (e.g., timing and channel frequency hopping sequence) duringmaster response state 214. A connection state 216 starts with a packetwith no payload (e.g., a Bluetooth POLL packet) sent by the first deviceto verify that other devices have switched to the first device's timingand channel frequency hopping sequence. The other devices may respondwith any type of packet.

As shown in the example of FIG. 2, a relatively lengthy inquiryprocedure and paging procedure are typically used when connecting todevices for the first time. If some connection parameters are known(e.g., a network address), then the inquiry procedure may be bypassedand the paging procedure may be immediately initiated to establish theconnection. During the paging procedure, the other device may adapt itsnative clock to match the first device's clock using a timing offset. Insome embodiments, to transmit over the network, at least the channelhopping sequence, the phase of the sequence, and the channel access codemay be used.

FIG. 3 is a block diagram of a device 300 according to one embodiment ofthe present invention. Device 300 may be any electronic device with awireless interface, such as a mobile telephone, PDA, or laptop computer,and may be configured to acquire a machine-readable feature andautomatically connect to, or pair with, one or more other wirelessdevices. Device 300 includes a controller 302 that controls the overalloperation of device 300. Controller 302 may include one or moreprocessors (e.g., microprocessors) configured to executemachine-readable instructions. A memory unit 314 (e.g., RAM, ROM, hybridtypes of memory, storage device, hard drives, optical disc drives, etc.)may store a predetermined program or application for controlling theoverall operation of device 300 and store data input and output inmemory unit 314.

A camera module 322 may convert an image or a moving picture to adigital form, and controller 302 may store the digital form in memoryunit 314. A feature recognition module 320 may be configured to read amachine-readable feature (e.g., a printed or displayed indicia) usingcamera module 322 or an input device 318. Controller 302 may storefeature information in memory unit 314. Input device 318 may also beused to read a feature and may include a scanner (e.g., barcodescanner), RFID reader, magnetic strip reader, keyboard, mouse, or anyother type of input device that may be used to read, scan, acquire, orotherwise process a machine-readable feature. A display device 316 mayinclude a Liquid Crystal Display (LCD), CRT display, or plasma displayfor displaying various information (including, e.g., machine-readablefeatures such as barcodes) and may be controlled by controller 302.

Device 300 may also include one or more wireless interfaces. In theexample of FIG. 3, device 300 includes a Bluetooth interface 304, an RFinterface 306, and a Wi-Fi interface 308, but more or fewer types ofwireless interfaces may be included in device 300 in other embodiments.RF interface 306 may include an RF transceiver to perform wirelesscommunication with a base station and amplify and filter transmitted andreceived signals to allow an RF signal to be exchanged betweencontroller 302 and the base station.

Bluetooth interface 304 may perform wireless communications with otherBluetooth devices and allows an RF signal to be exchanged betweencontroller 302 and other Bluetooth devices. In particular, Bluetoothinterface 304 may broadcast a request message for a connection with oneor more Bluetooth devices relating to the connection parameters accessedfrom optically acquired machine-readable features. Wi-Fi interface 308may perform wireless communications with other Wi-Fi devices and allowconnection parameters to be exchanged between controller 302 and otherWi-Fi (e.g., 802.11) devices.

An audio processor 310, which may include or be connected to one or moreof an acoustic coupler, a digital signal processor, and memory, may beconfigured to output audio signals using speakers 312 and to receiveaudio signals using a microphone 311. Audio processor 310 may encode anaudio signal into a sequence of modulated tones (e.g., using audiofrequency-shift keying (AFSK), dual-tone multi-frequency (DTMF)signaling, or some other suitable audio modulation technique). Whenreceived by another device, the modulated tones may be decoded andconverted into wireless connection parameters (e.g., a Bluetoothaddress), as described in more detail below. In some embodiments, themodulated tones may include tones of a frequency outside the humanhearing range of approximately 20 Hz to 20 kHz. Additionally oralternatively, the modulated tones may be decoded and converted into aunique identifier that is used, for example, as a key for a table in arelational database. The key may be used to lookup wireless connectionparameters from the database. In this way, an audio signal may be usedto facilitate device connection or device pairing.

In a typical usage scenario, a user of device 300 may activate inputdevice 318, camera module 322, or microphone 311 to acquire amachine-readable feature. For example, a barcode, watermark, image,symbol, or hologram may be optically acquired by a digital cameraassociated with device 300. As another example, microphone 311 may beused to receive audio signals. In response to acquiring themachine-readable feature, device 300 may execute an automatic connectionor pairing procedure with one or more other devices associated withconnection parameters accessed via the machine-readable feature. Forexample, at least some of the connection parameters may be actuallyencoded and stored in the machine-readable feature. To access theconnection parameters, the encoded machine-feature feature may bedecoded and converted into a digital representation of the feature.Additionally or alternatively, at least some of the connectionparameters may be accessed from a storage device using themachine-readable feature. For example, the machine-readable feature maybe decoded and converted into a digital representation. At least part ofthis digital representation may then be used as, or contain, a key in atable in a relational database that stores the connection parameters.Another part of the digital representation may be used as, or contain, anetwork address or URL associated with the database (e.g., a URL ornetwork address used to access the database). The relational databasemay be stored locally on device 300 or on a network storage device. Asyet another example, the machine-readable feature may be decoded to anetwork address or URL of a storage device (e.g., a network storagedevice) that stores the connection parameters.

FIGS. 4A and 4B show some illustrative devices and the device'sassociated machine-readable features. FIG. 4A shows a wireless speakersystem 402 with a machine-readable feature 404. In the example of FIG.4A, machine-readable feature 404 may take the form of a miniaturedisplay with, for example, a linear barcode; however, any othermachine-readable feature (e.g., magnetic strip, RFID tag, matrixbarcode, or encoded image) may be associated with wireless speakersystem 402 in other embodiments. A device that wishes to connect to orpair with wireless speaker system 402 may scan, optically acquire, orread machine-readable feature 404 using a camera, barcode scanner, ormagnetic strip reader integrated with or attached to the device. Becausewireless speaker system 402 includes audio support, in some embodiments,button 403 of wireless speaker system 402 may be used to initiate anautomatic pairing process using audio signals. For example, when a userpresses a button 403 of wireless speaker system 402, it may cause anaudio controller within wireless speaker system 402 to produce a seriesof modulated tones (e.g., using audio frequency-shift keying (AFSK),dual-tone multi-frequency (DTMF) signaling, or some other suitable audiomodulation technique). The modulated tones, when received by amicrophone or sound recording device of a device (e.g., microphone 311of device 300 (FIG. 3)), may be converted into a spectrogram and atime-frequency analysis may be performed on the spectrogram. Thespectrogram may be used as a fingerprint for a unique key that is usedto lookup connection parameters (e.g., Bluetooth address and securityparameters) in a database. Alternatively, the time-frequency analysismay be used to derive connection parameters directly from thespectrogram. For example, in one embodiment, an audio converter is usedto convert aspects of the received audio signals (e.g., frequencies ofpeak intensity) into raw PCM data which is then converted into binarydata. This digital representation of the audio signal may include atleast some of the connection parameters used to automatically connect toone or more other devices.

FIG. 4B shows a device 410 with an integrated display 412. Integrateddisplay 412 may include any type of display, including CRT, LCD, orplasma display. Integrated display 412 may be part of a larger device,such as a remote control, a mobile telephone, laptop computer, printer,scanner, or any other electronic device with wireless networkfunctionality. A processor within device 410 may cause integrateddisplay 412 to display a machine-readable feature 408, which in theexample of FIG. 4B takes the form of a linear barcode, or QR code.Machine-readable feature 408 may be static, dynamic (e.g., change overtime), and may be configured by a user of device 410. For example, asdiscussed in more detail below, some machine-readable features are usedto access other network devices, wireless networks, remote services,system clock and other synchronization information. Certainsynchronization information may help speed up the connection setupprocess in various ways by providing necessary and/or advantageousinformation, e.g. a known-valid estimate of the system clock, theclock's phase, and other synchronization information may be included inmachine-readable feature 408. In this way, some messages (or exchangesof messages) may be bypassed saving valuable connection and setup time.In some embodiments, machine-readable feature 408 may be updated (e.g.,re-encoded and displayed) continuously to reflect changes in systemclock and synchronization information. If device 410 is to be used asthe master device in a master-slave protocol that adopts the master'sclock as the system clock, then machine-readable feature 408 may includean indication of device's 410 own clock (as well as related phase offsetinformation). Other information included in machine-readable feature 408which may change over time includes encryption keys, PIN values, usagerequirements, power requirements, current battery levels, deviceaddresses, and other suitable user settings and options.

FIG. 5 shows illustrative connection parameter formats according to oneembodiment of the present invention. As described above,machine-readable features used for device connection or device pairingmay take the form of many different indicia and features. For example, alinear barcode 502, a QR code 504, or both, may both be used tofacilitate device connection or device pairing in accordance with thepresent invention. Other types of machine-readable features may include,for example, characters, symbols, labels, pictorial icons, graphics,images, watermarks, holograms, or any other printed or displayed indiciathat may be used to encode, represent, or lookup information.Machine-readable features may also include non-printed features, such asmagnetic strips, audio signals, radio frequency identification (RFID)tags, and various other types of sensors and tags embedded or attachedto electronic devices and audio signals.

When a device acquires or reads a machine-readable feature, such aslinear barcode 502 or QR code 504, the feature may be decoded into abinary string of a particular format or formats. For example, format 501and 503 may be used to support an automatic device connection or pairingprocess. Format 501 may include at least a length field 505, a mode flag506, a security flag 508, an address field 510, a clock field 512, alink key field 514, and a PIN field 516. Length field 505 may include anindication of the length of format 501. Mode flag 506 may indicatewhether or not negotiated protocols should be used (for example, if morethan one protocol (e.g., Wi-Fi and Bluetooth) is supported). Securityflag 508 may indicate whether or not a security mode is required for theconnection. Address field 510 may include a network address (e.g.,Bluetooth address) of the device. Address field 510 may include a prefixto indicate what type of address (e.g., corresponding to which protocolor standard) is included in address field 510. For example, variousnetwork addresses (e.g., MAC addresses, BSSIDs, SSIDs, Bluetoothaddresses, IP addresses, etc.) may be supported. The prefix may be usedto help identify the type of address as well as protocols or standardssupported by the device. Clock field 512 may include varioussynchronization information (e.g., the device's real-time clock, anestimate of the system clock, or a phase offset). Link key field 514 mayinclude one or more encryption keys (e.g., link keys, session keys, orauthentication keys), signed certificates, or other securityinformation. Finally, PIN field 516 may include the PIN or access codeassociated with the connection.

Embodiments of the invention include a network camera capable ofconnecting to a wireless network. The network camera may be capable ofconnecting to one or more online services for providing audio, video andimaging services. For example, the camera may connect directly to anonline video site to upload video data, or an online image repository toupload images. The camera may also connect to an online videoconferencing service to provide audio or video data in conjunction withvideo calls. Authentication information for one of more such servicesmay be contained in a machine-readable feature as described above alongwith information to connect to one or more wireless networks. Suchinformation may include an identifier of the network service andcredentials to sign into the network service, such as a username andpassword. When the device authenticated with the online service, thedevice may negotiate an authentication token that is independent fromthe user's credentials such that the credentials may change withoutimpacting the camera's access to the service. Furthermore thecredentials stored in the machine-readable identifier may be a one-timetoken or password usable by the camera to authenticate with the service,such that a discarded identifier cannot be used to authenticate asubsequent device with the service.

Format 501 may be used to initiate a connection to one or more devicesidentified in address field 510. In some embodiments, more than oneaddress field (as well as other related fields) may be included informat 501 to support connections to more than one device. For example,a laptop computer may access a single machine-readable feature toconnect to a plurality of devices and peripherals. In this way, anygeneric device that has not connected to that plurality of devices andperipherals previously may easily initiate automatic connections withthe plurality of devices and peripherals using a single read of amachine-readable feature.

As described above, in some embodiments, machine-readable features mayalso be used to determine the applications supported or required by adevice (or by a connection with the device). Format 503 may be used toindicate such applications and may include a length field 517, typefields 518, 522, and 526, and application identifier fields 520, 524,and 528. For example, some piece of software or code may be necessary toenable or configure communication with the device. This software or codemay include, for example, a device driver, an operating system update, acommunication utility, an antivirus program, or any other applicationthat may be required to connect to the device. Some of the applicationsidentified in format 503 may be actually required to interface with thedevice or some service running on the device. Other applications may bemandated by a policy (e.g., a security policy) in force on the device.Length field 517 may include an indication of the length of format 503.

Type fields 518, 522, and 526 may be used to determine whether theapplication is supported or required. Supported applications may be usedto indicate what applications and services are available on the device.Required applications may include a basic set of applications necessaryfor successful interaction with the device. Before a first device ispermitted to connect to another device, a determination may be made byother device that the first device has all required applicationsinstalled and that these applications are currently running If a deviceattempts to connect without a required application or applicationsinstalled, the connection attempt may be automatically terminated and anerror reported.

In addition, the type field may be used to indicated whether or not anapplication should be automatically accessed, downloaded, or transferred(“auto-dl” type) to the device on or after requesting a connection. Forexample, a device driver (or other piece of software) necessary forcommunication with the device or online service may be automaticallydownloaded to the connecting device. In such cases, the applicationidentifier field may include a URL or link to the driver or other pieceof software. After decoding the machine-readable feature, a device mayautomatically download applications marked with the “auto-dl” type ifthe device does not already have the applications installed. Applicationidentifier fields 520, 524, and 528 may each include a uniqueapplication identifier or signature used to identify the application.Although only three applications are identified in the example of FIG.5, more or fewer applications may be included in format 503 in otherembodiments.

FIGS. 6, 7, and 8 show illustrative processes for supporting thefacilitated device connection or device pairing of the presentinvention. FIG. 6 shows an illustrative process 600 for automaticallyconnecting to an AP or device using a machine-readable feature accordingto one embodiment of the present invention. At step 602, themachine-readable feature is acquired by a device. For example, cameramodule 322 (FIG. 3) or input device 318 (FIG. 3) may be used to acquirean image. As another example, a barcode, magnetic strip, or RFID tag maybe read at step 602. In some embodiments, an application or computerprogram running a user's device instructs the user to point to a cameraor other input device of the user's device at another device to whichthe user wishes to connect. The application or program then scans asurface or packaging of the device to which the user wishes to connectand locates the machine-readable feature in order to acquire thefeature. After the machine-readable feature is acquired at step 602, oneor more of the remaining steps of process 600 may be executed orcompleted automatically without any intervention from a user. At step604, the feature may be decoded. Controller 302 (FIG. 3) may decode theencoded machine-readable feature into its raw data (e.g., binary) form.For example, the machine-readable feature may be a barcode and the rawform may included one or more of formats 501 and 503 (both of FIG. 5).

In some embodiments, the machine-readable feature may include awatermark or hidden embedded feature (such as a hidden digital image).This watermark or hidden embedded feature may not be visible ornoticeable to the human eye, but it is after acquired using a digitalcamera, scanner, or other input device it may be isolated and decodedinto connection parameters, a unique key used to lookup connectionparameters, or both. Various image processing algorithms and techniquesmay be used to decode the machine-readable feature, including patternreorganization, character recognition, feature extraction, and dimensionreduction.

At step 605, a determination is made whether a PIN (or other accesscode) is required for the connection. For example, for the Bluetoothprotocol, three security modes are defined in the Bluetooth GenericAccess Profile (GAP). Security mode 1 is a non-secure mode in which aBluetooth device does not initiate any security procedures. In securitymode 1, both authentication and encryption may be bypassed. Securitymode 2 is a service-level enforced security mode in which access toservices and devices are controlled. Various security policies and trustlevels are defined for simultaneously running applications and serviceshaving varying security requirements to permit access to an authorizedpart of the entire set of device services. Security mode 3 is alink-level enforced security mode in which authentication and encryptionare provided based on link keys shared between Bluetooth devices. Anessential difference between security mode 2 and security mode 3 is thatin security mode 2 the Bluetooth devices initiate security proceduresafter the channel is established (at the higher layers), while insecurity mode 3 the Bluetooth devices initiate security proceduresbefore the channel is established (at the lower layers). Twopossibilities exist for a device's access to services depending on thedevices trust status. A “trusted” device has unrestricted access to allservices. An “untrusted” device doesn't have fixed relationships and itsaccess to services is limited. For services, three security levels aredefined: services that require authorization and authentication,services that require authentication only, and services that are open toall devices.

In the Bluetooth pairing procedure, for example, a master device may askfor PIN input from a user of the master device. After a connection isattempted after input of the PIN code, a user of a slave device may alsobe prompted to input a PIN. If the user of the slave device inputs a PINcode that is the same as that input by the user of the master device,the master device and the slave device may exchange link keys assignedaccording to the input PIN codes, Bluetooth device addresses (BD ADDR),and random numbers (RAND). The link keys are provided to the masterdevice and slave device to be used in authentication between the masterand slave device.

After a new connection between Bluetooth devices is established, acommon link key assigned according to a PIN code may be used between theBluetooth devices for authentication. If an available common link keydoes not already exist on the Bluetooth devices, a link manager mayautomatically perform an initialization procedure to exchange link keys.If a determination is made by the master device or the slave device thata PIN is required for the connection, then at step 610 the master deviceor the slave device may compare the PIN of the other device to its ownPIN. After a successful comparison at step 610, or if PIN values are notrequired to be exchanged, at step 612 link keys may be exchanged betweenthe master device and the slave device. As discussed above, link keysare provided to the master device and the slave device to be used inauthentication between the master device and the slave device. At step614, the connection between the master device and the slave device maybe completed and maintained until released by a user at the masterdevice or a user at the slave device. At step 616, one or moreconnection parameters (e.g., one or more of the parameters defined informats 501 and 503 (both of FIG. 5)) may then be stored to the masterdevice, the slave device, or both devices. For example, these connectionparameters may be used in subsequent connections by the same devices inorder to reduce setup and connection time.

In practice, one or more steps shown in process 600 may be combined withother steps, performed in any suitable order, performed in parallel(e.g., simultaneously or substantially simultaneously), or removed.

FIG. 7 shows illustrative process 700 for processing an audio signalused to facilitate connection or pairing between devices according toone embodiment of the present invention. At step 700, a user mayinitiate a connection request. For example, a user may press button 403(FIG. 4) of a wireless speaker or audio system. Initiating a connectionrequest may cause an audio controller within a wireless audio system toproduce a series of modulated tones (e.g., using audio frequency-shiftkeying (AFSK), dual-tone multi-frequency (DTMF) signaling, or some othersuitable audio modulation technique). In some embodiments, the modulatedtones may include tones of a frequency outside the human hearing rangeof approximately 20 Hz to 20 kHz. The modulated tones are received by adevice at step 704 by, for example, a microphone of the device (e.g.,microphone 311 of FIG. 3). After the audio signal is received at step704, one or more of the remaining steps of process 700 may be executedor completed automatically without any intervention from a user. Forexample, the received audio signal may be decoded and analyzedautomatically in response to receiving the audio signal at step 706. Insome embodiments, the audio signal may be converted into a spectrogramand a time-frequency analysis may be performed on the spectrogram. Othersuitable audio processing, such as filtering, equalization,echo-cancellation, and reverberation-cancellation, may also be performedat step 706. At step 706, a digital representation of the received audiosignal may be created and stored. The digital representation may expressthe pressure wave-form as a sequence of symbols, for example, binarynumbers. This digital representation may then be processed using digitalcircuits, such as audio processor 310 (FIG. 3), controller 302 (FIG. 3),and digital signal processors.

At step 708, connection parameters are determined from the digitalrepresentation of the received audio signal. For example, the digitalrepresentation may take the form or one or more of formats 501 and 503(both of FIG. 5). Connection parameters may include one or moreaddresses (e.g., Bluetooth addresses, MAC addresses, IP addresses,BSSIDs, etc.), one or more clock estimates, other synchronizationinformation, and security information (e.g., various link keys, signedcertificates, PIN values, etc.) used in the connection process. At step710, a determination is made whether a PIN (or other access code) isrequired for the connection. If a determination is made that a PIN isrequired for the connection, then at step 712 a comparison of the slavedevice's PIN and the master device's PIN may be made. After a successfulcomparison at step 712, or if PIN values are not required to beexchanged, at step 714 link keys may be exchanged. As discussed above,link keys are provided to the master device and the slave device to beused in authentication between the master device and the slave device.At step 716, the connection may be completed and maintained untilreleased by a user at the master device or a user at the slave device.At step 718, one or more connection parameters (e.g., one or more of theparameters defined in formats 501 and 503 (both of FIG. 5)) may then bestored to the master device, the slave device, or both devices. Forexample, these connection parameters may be used in subsequentconnections by the same devices in order to reduce setup and connectiontime.

In practice, one or more steps shown in process 700 may be combined withother steps, performed in any suitable order, performed in parallel(e.g., simultaneously or substantially simultaneously), or removed.

FIG. 8 shows illustrative process 800 for negotiating connectionprotocols according to one embodiment of the present invention. Asdescribed above, often times two or more devices may support more thanone wireless standard or protocol. For example, two devices may supportconnections using more than one of 802.11, Bluetooth, IrDA, UWB,Z-Wave®, ZigBee®, ANT™, and Bluetooth Low Energy (also known asBluetooth 4.0). Each of these connection types may be associated with atransmit power specification (e.g., a minimum transmit power) and range.Using a protocol with a higher than needed transmit power may reducebattery life for a mobile device. Using a protocol with a longer thanneeded range may increase interference with other devices using the sameor different protocol. As such, in some embodiments, when facilitated(e.g., automatic) wireless connections are desired, a protocolnegotiation technique may be used to increase battery life of one ormore of the devices, to decrease interference with neighboring wirelessnetworks, or both.

Depending on the anticipated mobility of the devices, the anticipatedapplications to be used on the devices, and a power requirementsanalysis, the most appropriate protocol may be negotiated automatically.In some embodiments, the protocol with the lowest transmit power orrange is selected for use unless that protocol is not suitable for theanticipated usage of the devices. In some embodiments, the protocol withthe strongest security policy (e.g., encryption or authentication) isselected for use unless that protocol is not suitable for theanticipated usage of the devices. In some embodiments, the protocol withthe lowest transmit power or range and the strongest security policy(e.g., encryption or authentication) is selected for use unless thatprotocol is not suitable for the anticipated usage of the devices.

At step 802, connection parameters may be accessed. For example, amachine-readable feature may be acquired as described in process 600(FIG. 6) or an audio signal may be received as described in process 700(FIG. 7). At step 804, supported protocols may be negotiated between thedevices wishing to connect. For example, a supported protocol “query”packet may be exchanged between the devices. Alternatively, supportedprotocols may be derived directly from the accessed connectionparameters. As described above, address field 510 (FIG. 5) may include anetwork address (e.g., Bluetooth address) of the device. Address field510 (FIG. 5) may also include a prefix to indicate what type of address(e.g., corresponding to which protocol or standard) is included in theaddress field. In some embodiments, this address prefix is used todetermine which protocols or standards are supported by the device.

At step 806, the power requirements of the devices may be analyzed. Forexample, both devices may be on AC power, one device may be on AC powerand one device may be on battery power, or both devices may be onbattery power. Battery life remaining levels may also be accessed atstep 806. For example, a device may send an indication of the device'sremaining battery power to another device during the connection process.Alternatively, battery life levels and power requirements may beincluded in the machine-readable feature, if dynamic machine-readablefeatures are used. In this way, a device may read power requirements ofanother device directly from a machine-readable feature.

At step 808, anticipated usage requirements may be analyzed. Forexample, devices may require only intermittent communication withcertain devices (e.g., some peripherals such as printers) or moreconstant communication (e.g., some peripherals such as input devices andAPs). Usage requirements may also include anticipated usage range. Forexample, PANs including Bluetooth devices are associated with a morelimited range than WLAN devices, such as 802.11 devices. At step 808, anindication of the anticipated range may be communicated from the deviceinitiating the connection to another device to which the connectingdevice wishes to connect. Depending on the anticipated range, certainprotocols may not be suitable for the facilitated connection. At step810, a connection may be initiated based at least in part on the powerrequirements analysis, the anticipated usage requirements, and thesupported protocols of the devices.

If the anticipated usage requirements (e.g., range) is unsuitable for aPAN connection, then PAN connection types may be eliminated fromconsideration (or assigned a lower priority). If the analyzed powerrequirements indicate that one or more devices is on battery power, thenhigher transmit power protocols may be eliminated from consideration (orassigned a lower priority). If both devices are on battery power, thenan even lower priority may be assigned to higher transmit powerprotocols.

At step 810, the connection type with the highest priority may beattempted first and then all remaining connection types may be attemptedin priority order until a valid connection is created. Priorities may beweighted based on user preferences and user-configurable. In this way,the most appropriate protocol given the power requirements of thedevices and the anticipated usage requirements of the devices may beselected for a connection.

At step 812, a determination may be made if additional connections areto be initiated. For example, as described above, a device may wish toconnect automatically to a plurality of peripherals and other devices byaccessing a single machine-readable feature. If additional connectionsare desired, then process 800 may return to step 804 to negotiatesupported protocols with another device. If no additional connectionsare desired, the connection completes at step 812 and is maintaineduntil the connection is released by one of the connected devices.

An embodiment of the present invention may include a computing devicehaving a network interface and a processor. The network interface may beconnected to a computer network to which a network camera is alsoconnected. The computer network may be a wireless network, a wirednetwork, or a network with both wireless and wired access. For example,the network camera may be connected to the computer network wirelesslyvia WiFi, and the computing device may be connected to the computernetwork via an Ethernet cable.

In embodiments of the invention, the network camera may be madeavailable to applications running on the computing device as a UniversalSerial Bus (USB) camera connected directly to the computing device.Examples of such embodiments are shown in FIGS. 9 and 10, and discussedfurther below. USB cameras are common, and a number of computeroperating systems, including Microsoft Windows, Mac OS X and Linuxinclude drivers and support for USB cameras without requiring additionalsoftware and drivers. Furthermore, many operating systems includeapplication programming interfaces (APIs) that enable third partyapplications to access video from USB cameras. In embodiments of thisinvention, by making the network camera available to the operatingsystem as a USB camera, it may be accessed by third party applicationsimplementing these APIs without modification.

USB was designed as a means of sending data between a computer and aperipheral device for that computer. USB can be used to connect a numberof devices to a computer, including but not limited to keyboards, mice,webcams, and storage devices. The specification for implementing USB ismaintained and from time to time updated by the USB Implementers Forum.The USB 1.1, USB 2.0 and 3.0 Specifications as published by the USBImplementers Forum is hereby incorporated by reference in theirentirety.

While initially designed to allow communication between a computer(host) and a peripheral device, USB has since been used to communicatebetween two computers, or two devices. For example, USB can be used toconnect an external camera to a telephone such as an Apple iPhone, or aMotorola Droid telephone. A computer or device may implement one or moreUSB buses to which devices can be connected. Each USB bus has only onehost, which may be a computer as described above. An operating system onthe host may control the bus or have the ability to communicate withdevices connected to the bus. Devices connected to the USB bus may beassigned a unique seven-bit identifier to allow the operating system touniquely identify the device. This may allow up to 127 devices to beconnected to the bus. A device may have more than one bus. In such acase, up to 127 devices may be connected to each bus.

The host may communicate with any device on the bus by sending a packetand waiting for a response. Only one device on the bus may communicateat any one time. The packets may be of different types, including butnot limited to: a token packet, a special packet, a handshake packet,and a data packet. A USB device may have one or more logical endpoints,which can be used to communicate with the host. Communications between ahost and an endpoint at a device may be described as a pipe. The USBSpecification described a number of different parameters for a pipe andrelevant commands. For example, a pipe may have assigned a certainamount of bandwidth. A stream pipe may be used to send any type of data.A stream pipe may be used to conduct a bulk transfer, an isochronoustransfer and an interrupt transfer. A stream pipe may be controlled bythe host or the device. A message pipe may be used for host controlledcommunication, and it may allow bi-directional communication where thedevice may respond to a request from the host.

A USB host or USB controller may be a physical computer with a physicalUSB port connected to a physical USB bus. For example a computer with aphysical USB webcam connected to it. A USB controller and host may alsobe virtual. For example VMWare Fusion allows a virtualized computer torun on a Macintosh computer. The virtualized computer may have a virtualUSB controller and USB bus, wherein the virtualized computer is the hoston the bus. VMWare Fusion may represent to the virtualized computer thatcertain USB devices are connected to the virtual USB bus. These devicesmay be physical USB devices connected to the Macintosh computer, such asa webcam, or virtual devices such as a keyboard or mouse. The variousUSB devices may be represented to the virtual computer as connected tothe same USB bus even though some of them may be connected to differentphysical USB busses and some of them may be entirely virtual. Forexample, a printer may be connected to the Macintosh on a first physicalUSB bus as device number “1” and a webcam may be connected to theMacintosh on a second physical USB bus as device number 1. In order torepresent these devices as connected to the same bus on the virtualcomputer, VMWare must translate the device IDs such that there are notwo identical IDs on the bus, and ensure that USB packets are onlytransmitted on the virtual USB bus as permitted by the USB specificationand as expected by the operating system running on the virtual computer.

FIG. 9 shows an embodiment of the invention where a virtual USB bus isimplemented as a component running in kernel space of the operatingsystem giving it broad access to system-level memory space andcomponents. The virtual USB bus may be established by installing adriver or a kernel extension on the computing device. For example if thecomputing device is a Macintosh computer, the virtual USB bus may beimplemented as a kernel extension. In the embodiment shown in FIG. 9 aseparate component is used to implement the virtual USB camera. Thiscomponent may send USB commands to the virtual USB bus and communicatewith the network camera over the network connection. By separating thevirtual USB bus and USB camera, the amount of code running in kernelspace may be minimized and in turn reduce the risk of unauthorized codebeing executed in kernel space. FIG. 10 shows a different embodiment theinvention, where a single component implements both the virtual USB busand the virtual USB camera. This component is shown running in kernelspace. In another embodiment, the virtual USB bus may be implemented asa driver in a .DLL file, or by any other means permitted by theoperating system. The virtual USB bus may relay information to theoperating system about devices connected to it as well as commands sentby those devices. A person skilled in the art will understand that thesecomponents can be structured in a number of ways.

In an embodiment of the invention, the virtual USB bus may represent tothe operating system that a USB camera is connected to it. The USBcamera may be the only device connected to the bus, or one of manydevices connected to the bus. In one embedment, the code necessary torepresent the camera is included in the driver for the USB bus. Inanother embodiment, a separate driver or extension is used to representthe USB camera.

In one embodiment of the invention, the virtual USB bus relays USBpackets from the camera to the operating system, and from the operatingsystem to the camera. The USB camera may be represented as a singledevice complying with the USB Video Device Class, or it may berepresented as multiple devices with different functions, for example avideo device, an audio device, a motion detection device, a humaninterface device, and other devices relevant to a network camera.

The virtual USB camera may further establish a network connection to thephysical network camera. In an embodiment of the invention thisconnection may be established over an Internet Protocol (IP) connection.In some embodiments, the virtual USB camera may detect the networkcamera on the network using mDNS, zeroconfig DNS or Apple Bonjour. Thevirtual USB camera may use an existing IP address assigned to thecomputing device, or may assign a new address exclusively to communicatewith the network camera. The connection may be made using either IPv4 orIPv6. In another embodiment, the connection may be made using anotherlower level network protocol, such as Ethernet. When the connection ismade over IP, the virtual USB camera may communicate with the networkcamera over HTTP. For example, the virtual USB camera may send an HTTPrequest to the network camera to get basic configuration data. Thecamera may respond by sending such data as Extensible Markup Language(XML) data or data encoded using JavaScript Object Notation (JSON). HTTPmay be used to send configuration commands to the camera and to relayinformation back to the computing device.

In another embodiment of the invention, a driver for a virtual USBcamera may be installed on the computing device. The driver may simulatethe connection of a virtual USB camera to an existing USB bus. Theexisting USB bus may be physical or virtual.

In an embodiment of the invention, the virtual USB bus is monitoring thenetwork connection to detect when a network camera is attached to it.This may be done using mDNS, zeroconfig DNS, Apple Bonjour or anotherdiscover protocol. In an embodiment of the invention, the virtual USBbus may signal to the operating system that a USB camera was connectedto the bus once one is detected on the network. The virtual USB bus mayallow multiple network cameras to be connected to the same virtual USBbus, or may establish a separate virtual USB bus for each network cameradetected.

In an embodiment of the invention, the network camera implements a USBcamera stack, and is able to receive USB packets from the operatingsystem and send USB packets back to the operating system via the virtualUSB camera. In an embodiment of the invention, the virtual USB cameraencodes USB packets from the operating system using JSON and sends themto the network camera, that responds by sending a JSON encoded USBpacket to the virtual USB camera. The virtual USB camera may then decodethe USB packet and relay it to the operating system. In anotherembodiment, the network camera implements another communicationstandard, and the virtual USB camera maintains the USB connection to thebus and the operating system, and hides the details of the USBconnection from the network camera.

In an embodiment of the invention, video and audio data is sent from thecamera to the computing device using User Datagram Protocol (USP). Inone embodiment, this may include sending audio and video data over RealTime Streaming Protocol (RTSP). The virtual USB camera may receive theRTSP stream from the camera and translate it into USB packets and sendthem as a USB stream pipe to the operating system. In another it maymerely include sending encoded USB packets over UDP.

The virtual USB camera may send requests to the network camera tocontrol aspects of the video and audio data such as frame-rate, bitrate,resolution and other properties. In one embodiment of the invention,such requests are sent as encoded USB packets compliant with the USBVideo Device Class specification, whereas in other embodiments, therequests may be plain text encoded in JSON or XML.

In an embodiment of the invention where the network camera receivesencoded USB packets, the network camera may simulate multiple USBcameras connected to different computing devices. For example, eachcamera may be connected to a bus at each computer, and the networkcamera may receive encoded USB packets from each computing device. Thenetwork camera may send different video streams to each computingdevice, or send a single stream to multiple computing devices.

Embodiments of the invention may include a bus enumerator, such as shownin FIG. 11, that may include an application to enumerate and use a“broadcaster” camera as a regular USB webcam. For example, as shown inFIG. 11, a camera 1110 may be exposed to one or more third partyapplication(s) 1120 via bus enumerator 1104. Embodiments may includedeveloping a bus enumerator 1104 to create virtual Audio/Video USBdevices. For example, a virtual Audio/Video USB device may response allthe commands from MS UVC\UAC driver, such as shown in FIG. 11, e.g. UVC1116, Video PDO 1112, UAC 1115 and Audio PDO 1111. These may eachinteract with the third party application 1120, e.g. via MS Directshow1118 or other standardized suite, and communicate with the camera 1110via bus enumerator 1104, user mode service 1103, and IP component 1102,as discussed further below.

In embodiments, camera control and data may use networking protocol, andUSB webcam using USB (UAC,UVC) protocol, via application of thefollowing techniques to make a two software protocol talk to each other:

a. User mode service 1103 which communicates between Kernel mode busdriver through a specially defined IRP.

b. User mode service 1103 converts networking information to USBinformation and vice versa.

As conceptually shown in FIG. 12, an application or service 1203 may beexposed to a plurality of broadcaster cameras 1210-1212 supported bynetwork 1250 via a camera manager 1216. In embodiments, a camera supportservice 1230 may instantiate the camera manager 1216, e.g. based on auser request to provide video and/or audio stream(s) from one or morecameras 1210-1212 to remote application or service 1203. The cameramanager 1216 may, in turn, create memory instances 1290-1292 of thecamera object(s), one per instance of camera 1210-1212 found. The cameraobject may then manage the RTSP and HTTP controls via RTSP session(s)1242 and HTTP control(s) 1244, and deliver audio and/or video stream(s)from one or more cameras to the application or service 1203.

Embodiments may include an IP Component Interface, such as IP component1102. The IP Component may include API(s) configured, for example, toemulate USB XU controls to ease integration with an application orservice, and assist in virtual USB device emulation of the

Broadcaster camera. The IP component 1102 may be configured to performone or more of the following processes.

Discovery:

1. Verifies that the “Bonjour Service” (or other service discoverysoftware) is installed and running2. Does mDNS Discovery

Search for services of type:

-   -   “http. tcp”    -   “rtsp. tcp”

Filters using “prod” field—must be:

-   -   “Logi Broadcaster” (or other camera designator)

For each “Logi Broadcaster” (or other specified camera) found, retrieve:

-   -   version    -   serial number    -   HTTP control path and port    -   HTTP event path and port    -   HTTP broadcast path and port    -   MJPEG path    -   RTSP path and port    -   RTSP preview path and port

Camera hostname

-   -   IP—by calling gethostbyname(Camera hostname)

In embodiments, the gethostbyname( )results may be cached to speed upsuccessive look-ups (important for multi-homed PCs, since Windowsgethostbyname( )typically attempts DNS lookups via ethernet before wificonnection).

Online and Streaming States:

Periodically sends a JSON command to the camera over the controlconnection (every 2 seconds). This tells us if the camera is alive andwell or not, and whether it is in broadcast or streaming mode.Logi-Broadcaster ping is simply the following JSON string:

JSON command: {“name”:“get-streaming-mode”}

Tells mDNS to rescan services when Logi-Broadcaster ping times out (e.g.after 10 sec of no response).

Initial HTTP Connections:

Turns off Logi-Broadcaster ping to this camera.Creates connections to the camera using the control and events paths andports retrieved from mDNS.

HTTP Preview:

Creates 2 connections to the camera using the MJPEG path retrieved frommDNS. Uses one connection for control, and the second for streaming.

Broadcast mode:

Creates 2 connections to the camera using the broadcast path retrievedfrom mDNS. Uses one connection for control, and the second forstreaming.

RTSP Streaming:

Creates a RTSP session using the RTSP path and port retrieved from mDNS.

RTSP Preview Streaming:

Creates a RTSP session using the RTSP path and port retrieved from mDNS.

Encrypted Communications:

To encrypt HTTP communications between the client and the camera, apassword and the IP of the network interface through which the clientcommunicates with the camera may be used. On multi-homed clients, theWindows IP Helper function “GetBestInterface(camera IP)” may be used todetermine this interface.

FIG. 13 shows a design diagram for an exemplary networked environment1300 including a Broadcaster Camera Virtual Video device. TheBroadcaster camera 1310 is exposed to third party application(s) 1320(using media frameworks 1330) by means of two plugins; a Video digitizercomponent 1344 (e.g., for 3rd party applications that use legacy APIslike QuickTime or Sequence Grabber) and a CoreMediaIO plug-in 1342(e.g., for application using modern QTKit/AVFoundation frameworks). Bothplugins communicate with the WiFiStreamAgent 1318 in order to initiatevideo stream from the Broadcaster camera 1310. This communication mayuse, for example, XPC APIs. The WiFiStreamAgent 1318 may communicatewith the Broadcaster camera 1310 via WiFiDaemon 1312, and the Webcam SDK1316 may include RTP 1314 that stream video and/or audio from theBroadcaster camera 1310.

FIG. 14 shows a design diagram of a Virtual Audio device environment1400. Broadcaster camera 1410 may interact with webcam SDK 1416(including RTP 1414), via RTP, RTSP for streaming video and/or audioand/or HTTP (e.g. via WiFiDaemon 1412) for command and control.Broadcaster camera 1410 is exposed to the third party applications 1420as an audio input device by means of an Audio driver KEXT 1440. Audiodriver KEXT 1440 may be a loopback audio driver that feeds the audiodata received at the output channel back to the input channel. Howeverthe output channel is hidden from the third party applications. OnlyWiFiStreamAgent 1418 uses the output channel to send the audio datareceived from the Broadcaster camera 1410.

The WiFiStreamAgent 1418 may be a background process that drives bothaudio and video streaming sessions. This process may use webcam SDK 1416to communicate with the camera 1410 to access the camera controlinformation as well as audio and video streams.

Whenever a third party application initiates a video streaming, Pluginsmay communicate directly with the WiFiStreamAgent 1418 and get the videoframes.

However in the case of audio stream, the workflow may be slightlydifferent. The WiFiStreamAgent 1418 monitors the state of input channelof the audio driver KEXT 1440 using core audio framework 1430 APIs. Thevirtual device environment 1400 may be configured such that, wheneverany third party application uses a microphone of the Broadcaster Camera1410, WiFiStreamAgent 1418 receives a notification. WiFiStreamAgent 1418may then initiate an audio streaming session with the camera 1410, andsend the audio samples to the hidden output channel of the audio driverKEXT 1440, which is then sent to the input channel of the CoreAudioFramework 1430 and the application 1420, by the audio driver KEXT 1440.

FIG. 15 shows an exemplary design for a Broadcaster Control Interface,according to certain aspects of the invention. An interface such asshown in FIG. 15 may be advantageous, for example, in situations whereit is convenient for a third party application to control the propertiesof Broadcaster camera in the same way as they do for any other USBcamera.

For example, on certain operating systems, such as Mac OS X, it may notbe possible to create a virtual USB device as previously described.However, the inventors have found that a virtual USB bus 1510 (virtualhost controller) may be created and used instead. The virtual USB bus1510 may create a single virtual USB device 1512 with VID/PID matchingthe Broadcaster camera and expose only the control interface via IOKit1530. Host application 1520 can communicate with this interface toadjust the camera properties in the same way as in case of any other USBdevice. Virtual USB Bus 1510 forwards these commands via Virtual BusUserClient 1518 to a controller process 1540 in the user space. Thecontroller process 1540 interprets these commands and sends theappropriate commands to the Broadcaster camera using Webcam SDK 1516,and returns the response back to the Virtual USB bus 1510, which in turnreturns the response to the host application 1520.

In some embodiments, a computer-readable medium containingcomputer-readable instructions recorded thereon is provided. Forexample, memory unit 314 (FIG. 3) may store an application or computerprogram product accessible from a computer-usable or computer-readablemedium providing program code for use by or in connection with device300 (FIG. 3) or any instruction execution system. For the purposes ofthis description, a computer-usable or computer-readable medium mayinclude any tangible medium or apparatus that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.

The medium may be an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system (or apparatus or device), or apropagation medium. Examples of a computer-readable medium include asemiconductor or solid-state memory, magnetic tape, a removable computerdiskette, a random access memory (RAM), a read-only memory (ROM), arigid magnetic disk and an optical disk. Current examples of opticaldisks may include compact disc read-only memory (CD-ROM), a rewritablecompact disc (CD-R/W), and digital video disc (DVD).

A data processing system (e.g., including controller 302 (FIG. 3)) issuitable for storing and/or executing program code will include at leastone processor coupled directly or indirectly to memory elements througha system bus. The memory elements may include local memory employedduring actual execution of the program code, bulk storage, and cachememories which provide temporary storage of at least some program codein order to reduce the number of times code must be retrieved from bulkstorage during execution. Input/output or I/O devices (including but notlimited to keyboards, displays, pointing devices, etc.) may be coupledto the system either directly or through intervening I/O controllers.Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modems, and Ethernet cards are just a few of thecurrently available types of network adapters.

While various embodiments have been described above in the context of amaster-slave arrangement, any wireless protocol using any wirelesscommunication standard may be supported by the systems and methodsdescribed herein. In addition, although Bluetooth devices arespecifically used in some of the illustrative examples described herein,any electronic device may be adapted to support the facilitated deviceconnection and pairing techniques disclosed herein. For example, devicesmay initiate facilitated connections with other devices, peripherals andAPs. Furthermore, it is to be understood that the various embodimentsdescribed above may be used and adapted for other types of delays notspecifically described herein. It is to be understood that the examplesand embodiments described above are for illustrative purposes only andthat various modifications or changes in light thereof will be suggestedto persons skilled in the art, and are to be included within the spiritand purview of this application and scope of the appended claims.Therefore, the above description should not be understood as limitingthe scope of the invention as defined by the claims.

What is claimed is:
 1. A camera comprising: an optical sensor; awireless communication device; and a processor configured to establish aconnection with a remote web site, and stream a first video stream tothe remote website.
 2. The camera of claim 1, wherein the first streamis sent wirelessly.
 3. The camera of claim 1, wherein the processor isfurther configured to: establish a connection with a local device, andstream a second video stream to the local device.
 4. The camera of claim3, wherein the first and second video streams include differentresolutions.
 5. The camera of claim 3, wherein the first and secondvideo streams are sent using different formats.
 6. The camera of claim3, wherein the first and second video streams include different audioformats.
 7. The camera of claim 3, wherein the processor is furtherconfigured to establish a control channel between the local device andthe camera.
 8. The camera of claim 3, wherein the second stream is sentwirelessly.
 9. The camera of claim 3 wherein the camera is furtherconfigured to wirelessly obtain performance data related to the first orsecond video streams, and to adjust a parameter of the second videostream in response to the performance data.
 10. The camera of claim 3wherein the processor is configured to send the first and second videostreams over a common local area network.
 11. The camera of claim 1wherein the camera is further configured to wirelessly obtainperformance data related to the first video stream, and to adjust aparameter of the first video stream in response to the performance data.12. The camera of claim 1, wherein the processor is further configuredto control the first video stream via an application running on thecamera.
 13. The camera of claim 12, wherein the processor is furtherconfigured to: establish a connection with a local device, respond tocontrol signals sent from the local device, and control the applicationrunning on the camera based on the control signals.
 14. The camera ofclaim 13, wherein the processor is further configured to establish awireless connection between the local device and the camera.
 15. Thecamera of claim 1, wherein the processor is further configured to:establish a connection with at least one other camera, stream video fromthe at least one other camera to the remote website.
 16. The camera ofclaim 15, wherein the processor is further configured to: providecontrol signals to the at least one other camera, and control anapplication running on the at least one other camera based on thecontrol signals.
 17. The camera of claim 15, wherein the at least oneother camera comprises a plurality of cameras.
 18. The camera of claim15, wherein the processor is further configured to stream the video fromthe at least one other camera to the remote website with the first videostream.
 19. The camera of claim 15, wherein the processor is furtherconfigured to stream the video from the at least one other camera to theremote website as a second video stream.